Skip to content

GH-4251 Add the capability to parse required variables from templates to TemplateRenderer #4252

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

GH-4251 Add the capability to parse required variables from templates to TemplateRenderer #4252

wants to merge 6 commits into from

Conversation

sunyuhan1998
Copy link
Contributor

As mentioned in the issue, TemplateRenderer currently only supports rendering templates. The ability to also parse and extract the required variables from a given template would be highly beneficial, especially for proactively validating template correctness. This PR implements that capability.

Specifically, it:

  1. Adds a getRequiredVariables method to TemplateRenderer to extract the variable names required by the template;

  2. Includes corresponding unit tests to ensure correctness and stability.

Fixes #4251

@sunyuhan1998
feat: spring-projectsGH-4251 Add a getRequiredVariables method to `…
ae09200 
…TemplateRenderer` to parse the required variables from the template.

Signed-off-by: Sun Yuhan <sunyuhan1998@users.noreply.github.com>
@sunyuhan1998
Merge branch 'main' into fix-issue-4251
ac4afef 
# Conflicts:
#	spring-ai-model/src/test/java/org/springframework/ai/chat/prompt/SystemPromptTemplateTests.java
@sunyuhan1998
fix: Remove the redundant imports
04312df 
Signed-off-by: Sun Yuhan <sunyuhan1998@users.noreply.github.com>
@sunyuhan1998
fix: Fix the import order.
9d60992 
Signed-off-by: Sun Yuhan <sunyuhan1998@users.noreply.github.com>
@sunyuhan1998 sunyuhan1998 mentioned this pull request Sep 10, 2025
Open
@ilayaperumalg ilayaperumalg added templating enhancement New feature or request labels Sep 23, 2025
@ericbottard ericbottard self-requested a review October 2, 2025 09:01
@ericbottard ericbottard self-assigned this Oct 2, 2025
@ericbottard
Copy link
Member

Hi @sunyuhan1998,
thanks for your contribution!

Could you please rebase against main and also add the following logic: not all implementations may support retrieving variable names. As a consequence, could you make the new method throw NotSupportedException and make it default

@sunyuhan1998
Merge branch 'main' into fix-issue-4251
c920cbf 
# Conflicts:
#	spring-ai-template-st/src/test/java/org/springframework/ai/template/st/StTemplateRendererTests.java
@sunyuhan1998
fix: Merged the main branch code and adjusted getRequiredVariables …
2e6e126 
…to handle cases where subclasses do not support this method.

Signed-off-by: Sun Yuhan <sunyuhan1998@users.noreply.github.com>
@sunyuhan1998
Copy link
Contributor Author

Could you please rebase against main and also add the following logic: not all implementations may support retrieving variable names. As a consequence, could you make the new method throw NotSupportedException and make it default

Thank you very much for your review. I agree with your comments. I have merged the code from the main branch and adjusted the getRequiredVariables method as you suggested. However, I couldn't seem to find the NotSupportedException class in the project, so I used OperationNotSupportedException instead. Do you think this is acceptable? Could you please review it once again? Thank you so much!

@ericbottard
Copy link
Member

Could you please rebase against main and also add the following logic: not all implementations may support retrieving variable names. As a consequence, could you make the new method throw NotSupportedException and make it default

Thank you very much for your review. I agree with your comments. I have merged the code from the main branch and adjusted the getRequiredVariables method as you suggested. However, I couldn't seem to find the NotSupportedException class in the project, so I used OperationNotSupportedException instead. Do you think this is acceptable? Could you please review it once again? Thank you so much!

That's the one I meant, sorry.

However, the more I look at this, the more I think this may be a rabbit hole, especially for the case you want to support: what about nested properties? what about method invocations on objects? what about x... ?
Each templating library (granted we only have one at the moment, but you opened a PR to submit one with jinja and I saw one using SpEL) may support different and complex semantics of things they can do with the model. The caller of TemplateRenderer is not capable of deciding whether the implementation will fail or not, in the general case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@ericbottard ericbottard Awaiting requested review from ericbottard

Assignees

@ericbottard ericbottard

Labels
enhancement New feature or request templating
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

TemplateRenderer should support retrieving required variables from the template.
3 participants
@sunyuhan1998 @ericbottard @ilayaperumalg